1. Field of the Invention
The present invention relates generally to the field of distributed computing with particular emphasis on a system and methodology providing typed event and notification services.
2. Description of the Background Art
Distributed computing is a type of computing in which different components and objects comprising an application can be located on different computers connected to a network. With the explosive growth of the Internet, distributed computing has become increasingly popular in order to simplify network programming and to realize a component-based software architecture. To support distributed computing, an object framework or model is defined, thereby specifying a set of standards about how objects communicate with one another.
Distributed applications must often employ specialized architectures and use specialized communication protocols, such as RPC (Remote Procedure Call), CORBA (Common Object Request Broker Architecture), and DCOM (Microsoft Distributed Component Object Model), to enable program components or objects to communicate with one another regardless of what programming language they are written in or what operating system they are running on. For example, CORBA is an architecture and infrastructure developed by the Object Management Group (OMG) that developers may use to create computer applications that work together over networks. For further description of CORBA, see e.g., “Common Object Request Broker Architecture Core Specification, Version 3.0” (December 2002), available from the OMG, the disclosure of which is hereby incorporated by reference.
Central to the CORBA architecture is the “Object Request Broker” (ORB) that acts as an “object bus” over which objects transparently interact with other objects located locally or remotely. A CORBA object is represented to the outside world by a defined interface with a set of methods. A particular instance of an object is identified by an object reference. The client of a CORBA object acquires a corresponding object reference for use as a handle to make method calls, as if the object were located in the client's own address space. The ORB is responsible for all the mechanisms required to find the object's implementation, prepare it to receive the request, communicate the request to it, and carry the response or reply (if any) back to the client. The object implementation interacts with the ORB through either an Object Adapter (OA) or through the ORB interface. In this manner, CORBA enables pieces of programs (i.e., components or objects) to communicate with one another regardless of what programming language they were written in or what operating system they are running on. A CORBA-based program from one vendor can interact with a CORBA-based program from the same or another vendor, on a wide variety of computers, operating systems, programming languages, and networks.
The CORBA framework provides client-server type of communications. To request a service, a client invokes a method implemented by a remote object, which acts as the server in the client-server model. The service provided by the server is encapsulated as an object and the interface of an object is described in an Interface Definition Language (IDL). The interfaces defined in an IDL file serve as a contract between a server and its clients. Clients interact with a server by invoking methods described in the IDL. The actual object implementation is hidden from the clients.
CORBA is widely used to implement distributed applications and web services. It enables interactions between a client process and an object server to be implemented as object-oriented RPC-style communications. However, application developers and users are faced with a number of challenges in developing, implementing, and supporting a distributed application employing these specialized architectures and communication mechanisms.
In the CORBA architecture, the core object request broker (ORB) is an object-oriented distributed platform primarily for traditional client/server applications. This platform supports a connection oriented, synchronous communication model. Other communication models are usually supported on the so-called Common Object Service (COS) level. For example, a standard CORBA request results in the synchronous execution of an operation by an object. If the operation defines parameters or return values, data is communicated between the client and the server. A request is directed to a particular object. For the request to be successful, both the client and the server must be available. If a request fails because the server is unavailable, the client receives an exception and must take some appropriate action.
The OMG Event Service decouples the communication between objects and supports the asynchronous exchange of event messages. The OMG Event Service introduces event channels which broker event messages, and defines two roles for objects: the supplier role and the consumer role. Suppliers produce event data and consumers process event data. Event data is communicated between suppliers and consumers by issuing standard CORBA requests. For further description of the OMG Event Service, see e.g., “Event Service Specification, New Edition: Version 1.0” (June 2000), available from the OMG, the disclosure of which is hereby incorporated by reference.
More recently, the OMG Event Service was extended and enhanced by the OMG Notification Service, which introduces the concepts of filtering and configurability according to various quality of service (QoS) requirements. For further description of the OMG Notification Service, see e.g., “Notification Service Specification, Version 1.0.1” (August 2002), available from the OMG, the disclosure of which is hereby incorporated by reference. Clients of the Notification Service can subscribe to specific events of interest by associating filter objects with the proxies through which the clients communicate with event channels. These filter objects encapsulate constraints which specify the events the consumer is interested in receiving, enabling the channel to only deliver events to consumers that have expressed interest in receiving them. Together, the Event Service and the Notification Service (hereinafter referred to together as the “Event and Notification Service”) address the following requirements which are not supported at the core ORB level: a distributed publish/subscribe, many-to-many communication model; unidirectional, de-coupled asynchronous event distribution; quality of service (QoS) requirements such as event/connection persistence; and event filtering.
These requirements have been addressed in traditional message oriented middleware (MOM) long before OMG's Event and Notification Service. Nevertheless, the OMG solution is based upon open standards, language independent, and interoperable within a CORBA environment. OMG's Event and Notification Service specifications define four kinds of event channels: untyped, structured, sequence, and typed. Implementing untyped, structured, and sequence channels is relatively simple and these three channels are supported by a number of commercial or open source products. However, event transfer interfaces of these three channels (i.e., untyped, structured, and sequence) are infrastructure-defined rather than user-defined (i.e., defined by an infrastructure instead of by users). Therefore, these channels usually require more application level dynamic manual code to perform event packing and unpacking operations (e.g., into CORBA “Any” or “Anys”). This may result in a number of problems including increased user code complexity, larger event size (in-band type codes), performance overhead (dynamic code and dynamic memory allocation), and so forth.
On the other hand, the use of a typed channel can avoid many of the above problems for both the supplier and consumer sides of distributed applications. However, implementing a typed event and notification channel has long been acknowledged as technically challenging. Existing typed channel implementations are based on the idea of routing typed events using an Interface Definitional Language (IDL) interface knowledgeable decoder and encoder to dynamically de-marshal and re-marshal messages as described in the OMG Event Service specification. In current implementations, encoders/decoders are typically implemented using DII (Dynamic Invocation Interface), DSI (Dynamic Skeleton Interface), IR (Interface Repository), or DynAny (Dynamic Any Interface) technologies. The resulting typed channel implementations are very inefficient (i.e., have performance issues) and are also subject to a number of restrictions and limitations (e.g., current implementations cannot handle events which contain valuetypes). Therefore, although typed events have much smaller event sizes and are more elegant and efficient for supplier and consumer applications, only limited support for typed event and notification channels is provided in current products.
What is required is a solution which simplifies the implementation of an efficient typed channel. The solution should have a substantially reduced performance overhead compared to current typed channel implementations. The solution should also remove the restrictions which hamper current typed channel implementations. For instance, the solution should support valuetypes and remote method invocation (e.g., over the Internet Inter-ORB Protocol). The present invention provides a solution for these and other needs.